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This paper summarizes our experience in communicating the elements of reasoning about correct¬ 
ness, and the central role of formal specifications in reasoning about modular, component-based 
software using a language and an integrated Web IDE designed for the purpose. Our experience 
in using such an IDE, supported by a ‘push-button’ verifying compiler in a classroom setting, re¬ 
veals the highly iterative process learners use to arrive at suitably specified, automatically provable 
code. We explain how the IDE facilitates reasoning at each step of this process by providing human 
readable verification conditions (VCs) and feedback from an integrated prover that clearly indicates 
unprovable VCs to help identify obstacles to completing proofs. The paper discusses the IDE’s usage 
in verified software development using several examples drawn from actual classroom lectures and 
student assignments to illustrate principles of design-by-contract and the iterative process of creating 
and subsequently refining assertions, such as loop invariants in object-based code. 


1 Introduction 

An IDE equipped with a formal verification system at its back end can facilitate an alternative style of 
developing software that involves using feedback from the verifier to locate and correct errors statically, 
instead of a more classical testing and debugging approach. This paper illustrates how such an approach 
can work in practice based on our experience in employing it to teach a software engineering course, 
where students are asked to develop software components that are provably correct with respect to a set 
of given specifications. 

The discussion in this paper is in the context of teaching analytical reasoning to undergraduate CS 
students. The overall details of our educational approach for teaching mathematical reasoning, including 
an evaluation of student learning over multiple years in two required courses at Clemson, may be found 
in MM- Details of the types of software component development and reasoning assignments given 
to students are the topic of [T]. The purpose of the present paper is to explain the iterative approach that 
students and software engineers, in general, can employ for developing verifiably correct software using 
the feedback from the Web IDE and its integrated prover. 

The IDE discussed in this paper is web-integrated, easy to use, and freely available online. It has been 
used at multiple institutions over the span of several years for teaching fQI and research ll^ purposes, 
and is designed for RESOEVE, an integrated specification and programming language supported by a 
push-button verifying compiler ll^ . The characteristics that distinguish the RESOEVE language and 
approach from most others include the following iTHl : 

• Mathematical theories used in specifying programming concepts are extensible and they are de¬ 
scribed in reusable mathematical units; The theories are purely mathematical and do not involve 
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any computational considerations. They are carefully engineered to ease automated proving. Num¬ 
ber theory and a theory of strings over arbitrary types (used in this paper) are some examples. 

• Specifications of programming concepts that encapsulate abstract data types are kept strictly sep¬ 
arate from implementations to facilitate design-by-contract |[2^ and to allow for multiple ways of 
realizing the same concept and permit efficiency trade-offs. Examples of such concepts include 
programming integers with computational bounds, arrays, stacks, queues, and lists. 

• The notion of clean semantics ll^ makes it inessential to introduce and reason about object refer¬ 
ences explicitly in typical user code. 

While the literature includes several integrated development environments based on formal tech¬ 
niques related to ours (see section for a complete description), the one closest in spirit to the IDE 
discussed in this paper is the online Dafny IDE ^2M . Eor most of the exercises discussed in this paper, 
Dafny could be used as well. However, the key difference that manifests itself the most for the purposes 
of this paper is our system’s usage of a VC generation system ifTSl that underlies the integrated Web IDE. 
Using the VCs and a supporting prover capable of revealing which VCs fail to prove, it is possible to de¬ 
termine why a proof was unsuccessful from givens in the context. However, unlike the Dafny approach, 
which is backed by Z3 1231 . the IDE presented here cannot be used to provide counter examples when 
verification fails. The integrated prover does not use the proof-by-refutation technique, thus requiring a 
different sort of debugging to take its place. Eor example, a user contrasts what goal needs to be proved 
from the givens, tries to understand which givens would be more useful in attempting to prove the goal, 
and then adjusts the code or assertions as needed. 

The reasoning process using the RESOLVE Web IDE is quite similar to what might be employed by 
one using a Coq-style proof assistant, except that the proofs to be done are mostly ‘obvious’ due to the 
simple nature of VCs arising from well-designed software llT9l . This characteristic has allowed us thus 
far to forego the need for manual proof assistance for VCs|^ 

To illustrate how the IDE helps produce correct code based on realtime feedback, we begin with a 
simple example that involves only the use of the Integer datatype. This is followed by two object- 
based erroneous code examples: one that is recursive, and another that is iterative. These are examples 
presented to students as part of a software engineering course at Clemson. In all cases, we follow 
an iterative approach that eventually leads to the correct code or adequate annotations. The discussion 
concludes with a non-trivial queue copy example code with invariants that students were asked to develop 
for an assignment using the iterative approach. We note that the examples discussed in this paper are 
meant to give an idea of the iterative process. Several more complex components are available at the 
Web IDE; even more can be created by logging in to the site. We conclude the paper with a discussion 
of the most related work and a summary. 


2 Understanding Design by Contract Using the IDE 

In this and following sections, we provide several illustrative examples, each building in complexity, 
that demonstrate the iterative process we envision when using the Web IDE to develop provably correct 
code. All examples discussed have a shared emphasis on the debugging aspect: that is, each requires 

*A proof assistant such as Coq or Isabelle 1291 is indeed necessary for proving the results in reusable mathematical units 
employed by the automated prover, but the focus of this paper is on code correctness and VCs, assuming that the necessary 
theorems have been established previously iQi. 
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sufficient knowledge of design by contract to correctly identify and amend a variety of errors in code or 
annotations based on interactive feedback from the prover in the form of VCs. 

The first, relatively simple example presents an operation that arithmetically swaps the values of 
two Integer objects. Taking advantage of the conceptual simplicity of the code comprising this initial 
example, we also use this as an opportunity to familiarize readers with RESOLVE style specifications, 
syntax, and layout of the Web IDE. More details on the design of the RESOLVE language and its IDE 
may be found elsewhere |[9l l3n[32]| . 

Upon opening our first example, Int_Swap_Example_Fac (Eig.[T]), students are presented with code 
for a single operation. Exchange, that takes two Integer objects, denoted I and J. The essence of the 
specifications that formally communicate what exactly Exchange does can be found in the ensures 
clause (the postcondition), where we formally assert that I = # J A J = #1. This assertion, when stated 
informally, can simply be read as “the outgoing value of I is equal to the incoming value of J and the 
outgoing value of J is equal to the incoming value of I. ’{^Notice also that there is no return value for the 
Exchange operation. Instead, we prefix each parameter with mode updates to indicate to clients that 
each of the Integer values passed will contain a purposeful value as specified by the conclusion of the 
operation. 


Welcome nabil. Current project: Default_Project 

Projects Components Import Export 

Log out Help 

U 

Int_Swap_Example iSl| 

sm 

[Build 

11 VCs II CCVerify ) 

[ Executable Java Rendering C Rendering ||-^j| — 

1 

Facility Int_Swap_Exaniple_Fac; 




2 

uses Integer_Template; 




4 

Operation ExchangeCupdates I: Integer; updates J: Integer); 




5 

ensures I = #J and J = #1; 




6 

Procedure 




7 

I := I + J; 




8 

J := I - J; 




9 

I := I - J; 




10 

end Exchange; 




11 





12 

end Int_Swap_Example_Fac; 





Eigure 1: Exchange operation with missing requires clause. 

Software developers are free to edit both the specifications (formal contracts) of Exchange, as well 
as its executable body (sandwiched between the Procedure and end keywords). When ready to verify 
the operation, students may invoke an integrated prover. The exact prover used is of less importance to 
the discussion in this paper. It’s worth noting here, however, that our system is supportive of three ap¬ 
proaches: one based on term-rewriting (accessible via the RWVerify button) If34ll . another that is currently 
under development and uses a congruence closure algorithm in conjunction with a matcher for quanti¬ 
fied expressions (accessible via CCVerify button), and (optionally) an external SMT solver]^ The second 
one that is designed to be just sufficient to prove VCs arising from program correctness (as opposed to 
arbitrary mathematical assertions) is summarized in section and that is the one used for the examples 
in this paper. 

Upon attempting to verify the Exchange operation, students are presented with a screen summarizing 
proof results, as shown in Eig. The system generates eight distinct VCs |[T5l . VCs are mathematical 


^In RESOLVE ensures clauses, # denotes the incoming value of a formal parameter. 
3Z3 (27] is currently being incorporated as a proving option. 
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assertions that are both necessary and sufficient for the code to be proven correct. To understand why 
there are eight VCs, we briefly describe the design-by-contract idea in this setting. Two VCs arise from 
the two conjuncts of the ensures clause of the Exchange operation, guarantees to be provided by the 
implementer of the code. Six VCs, two each for the requires clauses (preconditions) of each of the 
three statements in the code, namely that the sum or differences do not go outside computational integer 
bounds (i.e., inin_int and inax_int), for a total of eight VCs. This is because preconditions of called 
operations are the responsibility of the calling code in design-by-contract. Placing the cursor near the 
line number of a statement causes a box to appear referring to the names of one or more VCs generated 
if the statement produces VCs. 


iiVelcome nabil. Current project: Default Project 

Log out Help 

Projects Components Import Export 




Q j Search Capability ;^|j Obvious Flipping | Integer Template 

t^l Int_Swap_Example WLU 

Build II VCs II CCVerify | 

[ C'Executable n Java Rendering C Rendering 


1 Facility Int_Swap_Example_Fac; 

2 uses Integer_Template; 

3 

4 Operation ExchangeCupdates I: Integer; updates J: Integer); 

5 ensures I = #J and J = #1; 

6 Procedure 

® 7 I T I + J; 




VC: 0_1: Requires Clause of Sum in Procedure Exchange: 
JInt_Swap_Example_Eac.faC7) 

1 

jVC: 0_Z: Requires Clause of Sum in Procedure Exchange: 
Int_Swap_Example_Fac.faC7) 


VC0_7 


VC0_8 


VC0_1 

4 

VC0_2 

A 

VC0_3 


VC0_4 


VC 0_5 


VC0_6 

_ ® 


Figure 2: Proof attempt of Exchange operation with missing requires clause. 

Of the eight VCs, two are unable to be proven, as indicated by the yellow exclamation marks beside 
VC_01 and VC_02 (Fig.[^. The line numbers in code corresponding to the VC are given in parentheses. 
While VCs in general might arise from any number of sources within a block of executable code, those 
unable to be established here arise from the requires clause of the sum operation that is implicitly invoked 
when I and J are added via the + operator. We leave it to a reader to convince themselves that an overflow 
or an underflow can occur in this code only for the first statement. 

To aid students in arriving at the particular insight necessary to debug this code, we encourage them 
to interactively explore the unprovable VCs by mousing over context sensitive VC buttons appearing 
next to lines of code that generated VCs. Upon clicking any of these buttons, the panel on the right hand 
side of the Web IDE updates with relevant, finer grained information about the particular VC queried, 
including a succinct description of what must be established (the goal) and the various facts (givens) the 
system currently knowsj^ 

In terms of the Exchange example, it is easy to observe that the system is unable to infer from the 
givens that min_int <= (I + J) (VC 0_1) and (I + J) <= max_int (VC 0_2). It then becomes 
possible to infer that the system currently lacks knowledge suitable to realize that Integer overflow 
(or underflow) will not occur when the + operation is carried out. To remedy this, and ‘provide’ the 

parsimonious approach to the generation of givens is under research and several of the unrelated givens are expected to 
disappear in the next version of the IDE. 
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Welcome nabil. Current project: DefauIt_Project 

Projects Components Import Export 


Log out Help 


Q Int_Swap_Example Jj^l 


am 


1 Build II 

VCs II RWVerify || CCVerify | 

1 Executable Java Rendering C Rendering ||-|-|[ — 

1 

Facility Int_Swap_Example_Fac; 



2 

3 

uses Integer'_Template; 

NOT PROVED 


© 4 

Operation Exchange 

VC 0 1 (8) 


5 

(updates I: Integer; updates J: Integer); 



6 

ensures I = #J and J = #1; 



7 

Procedure 

Requires Clause of Sum in Procedure Exchange: 


© 8 

I := I + J; 

Int_Swap_Example_Fac.fa(8) 


© 9 

J := I - J; 

Goal; 


©10 

I := I - J; 



11 

end Exchange; 

(minjnt <= (I + J)) 


12 


Given: 


13 

end Int_Swap_Example_Fac; 

1. (J <= max_int) 



2. (min_int <= J) 

3. (I <= maxjnt) 

4. (min_int <= I) 

5. (Last_Char_Num > 0) 

6. (0 < max_int) 

7. (min_int <= 0) 


VC0_2 (8) 


■A 


Figure 3: Full display of a VC in the IDE. 


system with the assurance that this will not happen, students must defer to their knowledge of design- 
by-contract, amending the specification of Exchange with a suitable requires clauses as shown in Fig.|^ 
Again, under design-by-contract, the requirements become givens to be used in proofs. The figure shows 
fhaf fhe Web IDE successfully verifies fhe code using fhe improved operation specificafion. 


3 Debugging Recursive Code 

Eor fhe second example, we consider an example operafion which inverfs fhe order of ifems in a queue 
(see Eig. [^. The Invert operafion is specified in an enhancemenf (an exfension using specificafion 
inherifance) fo fhe Preemptable_Queue concepf and implemenfed in an enhancemenf realizafion, using 
only operations provided in fhe Preeinptable_Queue concepf. This separation of concerns makes if 
possible fo verify fhe enhancemenf realizafion in a modular fashion wifhouf referring fo or refining fo 
any one implemenfafion of Preemptable_Queue concepf. A preempfable queue differs from a regular 
queue in fhaf if has operations fo “injecf” new ifems af fhe fronf of fhe queue (i.e., preempf fhe regular 
queue order), in addifion fo regular queue operafions, such as Enqueue and Dequeue. 

A complefe specification of fhe Preemptable_Queue concepf is shown in Appendix In fhe 
Preemptable_Queue concepf, fhe confenfs of fhe queue are concepfualized as a mafhemafical sfring 
(a sfrucfure similar fo buf simpler fhan a sequence in Z, because no posifions are involved). So for fhis 
operafion, fhe ensures clause (or posf-condifion) sfafes fhaf fhe oufgoing value of fhe paramefer Q should 
be fhe mafhemafical reverse of fhe inpuf paramefer (denofed by #Q). Suppose fhaf fhis operafion is im¬ 
plemenfed using faulfy code such as is shown in Eig.[^ Three of fhe VCs are verified, buf VC 0_3 is nof. 
So as we did before, we encourage sfudenfs fo fake a close look af fhaf particular unprovable VC. 

In fhe goal, E ’ is fhe dequeued enfry, Q ’ is fhe concepfual siring fhaf slands for fhe value of fhe queue 
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Welcome nabU. Current project: De 

Projects Components Import E> 

fault Proiect Los out Hein! 

port 

Q 1 Int_Swap_Example [^j _ 

sm 

1 Build II VCs 11 RWVerify || CCVerify | 

j n Executable G Java Rendering G C Rendering 1 1 -f-j | -1 


1 Facility Int_Swap_Example_Fac; 

2 uses Integer_Template; 

3 

4 Operation Exchange 

5 Cupdates I: Integer; updates J: Integer); 

6 requires min_int <= I f J <= max_int;| 

7 ensures I = #J and J = #1; 

8 Procedure 


<B 9 

I := I + J; 

<S10 

j|’ 
1— 1 

l_i 

oil 

1—1 

II 

M 

12 

end Exchange; 

13 


14 

end Int_Swap_ExampI 


I NOT PROVED 
PROVED 


VC0_1 

(9) 


VC0_2 

(9) 


VC 0 3 

(10) 


VC0_4 

(10) 


VC 0 5 

(11) 


VC 0 6 

(11) 


VC0_7 

(4) 


VC0_8 

(4) 



Figure 4: Int_Swap_Exainple_Fac verified. 


passed into the recursive call of Invert, and Q stands for the value of the queue at the beginning of the 
procedure. The goal is that E ’ concatenated with the reverse of Q ’ is equal to the reverse of Q. In order to 
debug this VC a user may first write down the goal and then apply transformations until we can clearly 
observe why the goal is unprovable. The purpose here is to show a general process when the problem 
with the unprovable VC is less obvious]^ 

Goal: Q’ = Reverse(Q) 

Our first transformation will be to use given #1 and apply it to the left-hand side of the goal. We will 
label this transformation Step 1. 

Step 1: <E’> o Q’’ = Reverse(Q) 

Next, we will apply given #2 to transform the left-hand side once again: 

Step 2: <E’> o Reverse(Q’’’) = Reverse(Q) 

And then we apply given #3 to the right-hand side: 

Step 3: <E’> o Reverse(Q’’’) = Reverse(<E’> o Q’’’) 

Next, one can attempt to use a theorem from String_Theory, which defines string notations and re¬ 
sults involving those notations for mathematical strings. The theorem we need here states the following: 

^While we show the details of these steps here, in actual debugging, such a detailed analysis may not be necessary; under¬ 
standing of such principles as string concatenation is not commutative is straightforward and the problem may be inferred more 
readily. 
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Welcome nabil. Current project: DefauIt_Project 

Projects Components Import Export 


Log out Help 


Q Recursive_Iiivertinj ^|| PQ_Inverting_Capi fQ| Preemptable_Queui 


sm 


I Save I Rename I Delete 


□ Executable ][+)[“ 


1 Enhanceiuent PQ_Inverting_Capablllty for Preemptable_Queue_Template; 

2 Operation Invert (updates Q: P_Queue); 

3 ensures Q = ReverseC#Q); 

4 end PQ_Inverfcing_Capabtllty; 


Component Finder 






Globally_Bounded_Stack_Template 

> 

Preemptable Queue Template 

Copying_Capability > 

PQ_ 

lnteger_Template 

> 

Realizations > 

PQ_lnverting_Capability 

Real 

Location Linking Template 1 

> 

Enhancements 

Writing_Capability > 


Map_Template 

> 



I 

Preemptable_Queue_Template 



I 

Prioritizer_Template 

> 




Queue_Template 

> 




SI_Stack_Template 

> 




Search_Store_Tempiate 

> 



I 

Sequence.Template 

> 




Stack_Template 

> 




Statlc_Array_Template 

> 





Figure 5: Selection of an enhancement in the Web IDE. 


For all u, v : String, Reverse (u o v) = Reverse(v) o Reverse(u) 

This transformation will produce the following result: 

Step 4: <E’> o Reverse(Q’’’) = Reverse(Q’’’) o Reverse(<E’>) 

Finally, we apply a theorem that states that the reverse of a single-length string is itself, which gives 
us step 5: 

Step 4: <E’> o Reverse(Q’’’) = Reverse(Q’’’) o <E’> 

At this point, it is obvious to see that the goal is categorically false, as the concatenation operator is 
not commutative. Thus, the problem with the code is that the call to Inject is placing the dequeued entry 
on the wrong side of the recursively inverted queue. This example illustrates how the VC can serve as a 
guide to pinpoint the source of the error in formal reasoning. 

In the case, the correction is to fix the code: Specifically, fhe call fo Inject needs fo be replaced 
wifh a call fo Enqueue. 


4 Loop Invariants 

This secfion ouflines creation and iferafive development of loop invariants for code using object-based 
examples. Stacks and queues are abstract data types represented as objects in RESOLVE. Their behavior 
is specified in a Concept, which is an absfracf descripfion of fhe mefhods all implemenfafions musf 
confain. If concludes wifh a discussion of an assignmenf given fo sfudenfs in a junior level soffware 
engineering course. 








































Nabil M. Kabbani, Daniel Welch, et al. 


63 


Welcome nabil. Current project: Default Project 

Log out Help 

Projects Components Import Export 


j Q Recursive_Invertin] [^| 

sm 

|f VCs If RWVerify If CCVerify | ' [ Save ][ Rename ][ Delete 1 

[ Executable ||+|| “ 


1 Realization Recursive_Inverting_Realiz 

2 for PQ_Inverting_Capability 

3 of Preemptable_Queue_Template; 

© 4 Recursive Procedure Invertfupdates Q: P_Queue); 

5 decreasing IQI; 

6 

7 Var E: Entry; 

8 Var ten: Integer; 

9 

10 ten := EengthCQ); 

11 If ( Een /= 0 ) then 

©12 DequeueCE, Q); 

13 InvertCQ); 

©14 Inject(E, Q); 

15 end; 

16 end Invert; 

17 end Recursive_Inverting_Realiz; 


NOT PROVED 

VC 0 3 (4) 

4 

[ Ensures Clause of Invert: 

1 Recursive_Inveiting_Realiz.rb(4) 


1 

1 Goal: 


1 (Q' = Reverse(Q)) 


Given: 


1 1. (Q’ = (<£■> 0 Q")) 

2. CQ" = Reverse(Q"')) 

1 3, (Q = (<E'>0Q"')) 

1 4. (|Q|/=0) 

1 5. (P_val = IQI) 

1 6. Entry.Is_Initial(E) 

1 7. (IQI <= Max_Length) 

8. (Last_Char_Num > 0) 

9. (0 < max_int) 

10, (minjnt <= 0) 

11, (Max_Length > 0) 



Figure 6: Inverting Code with Error. 


4.1 Learning Iterative Invariant Development 

We begin with a simple example involving stacks to highlight the iterative steps we commonly see stu¬ 
dents working through with our Web IDE in reasoning about, and ultimately arriving at, appropriate 
assertions for loop invariants. Stacks, like queues, are modeled mathematically using strings; operations 
such as Push and Pop are specified using string notations. 

Eig.|^ shows an example operation presented in a classroom to teach the idea of invariants. Flip_ 
onto iteratively transfers entries from a source stack, S, to a destination stack, T, resulting in a version 
of T that is prefixed by a ‘flipped’ version of S. As expected, the intuition describing this outcome is 
formalized in the operation’s ensures clause by the following succinct assertion: T = Reverse(#S) 
o #T. With the operation’s input/output behavior formally expressed, students must turn to the task of 
deriving a suitable invariant for the while loop, expressed in RESOLVE using the maintaining clause. 
(The decreasing clause is used to document the progress metric necessary to prove termination.) 

Starting with a maintaining clause that simply reads “true”—which is an appropriate starting 
point for beginners to understand the process of developing adequate invariants—the system (unsurpris¬ 
ingly) fails to establish correctness. Aside from the obvious inability to prove VCs corresponding to the 
operation’s overall ensures clause, students using the Web IDE are able to see—with the help of the 
interactive VC buttons next to the line numbers—that VC 1_1 and 1_2 arising from calls to Pop and 
Push within the body of the loop are currently unprovable, as shown in Eig.[^ 

Examining VC 1_1, students are immediately informed that the requires clause of Pop (IS” | /= 
0) cannot be established. Referring to the list of available givens, students can see that while the system 
is aware that D’ /= 0, it still lacks any knowledge relating the length of S to the current depth, D. To 
address this roadblock and provide the prover with the information it needs to meet the precondition 
criteria of Pop, students might start by amending the maintaining clause with the assertion that IS | = D. 
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Welcome nabil. Current project: Defaiilt_Project Log out Help 

Projects Components Import Export 


Q Stack_Examples_F; [H|| [^[14 


I Build IfvCslI RWVerify || CCVerify | ' | Save 1| Rename |[ Delete | [ n Executable n Java RenderingPCRenderin^lfflr^ 


1 

Facility Stack_Examples_Fac; 


2 

3 

uses String_Theory; 

NOT PROVED 

<B 4 

Facility Rev_Stack_Fac is Stack_TemplateCChar_Str, 1) 

VC 1 1 (19) A 

5 

realized by Array Realiz; 


6 

<35 7 

Operation Flip_ontoCclears S: Stack; updates T: Stack) 

1 Requires Clause of Pop in Procedure Flip onto: 

8 

requires ISI + ITI <= 1; 

1 Stack_Examples_Fac.fa(19) 

9 

ensures T = ReverseC#S) o #T; 


10 

Procedure 


11 

Var Next_Entry: Char_Str; 

1 CIS"|/=D) 

12 

Var D: Integer; 

1 Given: 

13 


1. CD'/= 0) 

14 

D := DepthCS); 

1 2. (P val' = |S"|) 

15 

While CD /= 0) 

1 3. true 

16 

maintaining true; 

1 4, (1 <= maxjnt) 

CB17 

decreasing ISI; 

1 6, (Max Depth = 1) 

18 

do 

1 7, (|T| <= Max Depth) 

® 19 

PopCNext_Entry, S); 

1 8, (jsi <= Max Depth) 

1 9, ((|S| + |T|) <= 1) 

<S20 

PushCNext_Entry, T); 

1 10. (Last Char Num > 0) 

21 

D := DepthCS); 

11. (0 < max_int) 

22 

end; 

1 12. (minjnt<=0) 

23 

end Flip onto; 


24 


VC 1 2 (20) A 

25 




Figure 7: Loop with insufficient invariant. 


Sure enough, upon re-running the prover, students are given validation in the form of a green checkmark, 
indicating that one roadblock to verification of the current operation has been successfully dealt with. 

In motivating further construction of the maintaining clause, students once again look to unproven 
VCs as a guide to development. In this case, looking specifically fo VC 2_2, students can see that the 
ensures clause to the overall operation is still unable to be established. Using this insight, combined with 
the goal this VC is attempting to establish—specifically, that T’ = (Reverse (S) o T)—one way for 
students to proceed is to simply append this assertion to the evolving maintaining clause, yielding | S | 
= D and T = (Reverse(#S) o #T). Upon doing so, students can indeed see that the prover is now 
able to establish the ensures clause of the operation (indicated by VC 2_3), but is unable to establish the 
VC corresponding to the invariant of the while statement—suggesting that something is still lacking from 
the assertion. However, in examining the (now provable) goal of the overall ensures clause addressed 
in the previous step, students can see that it reads as follows: (Reverse (S) o T) = (Reverse (S) 
o T). Thus, mirroring the same technique and intuition employed to make the ensures clause provable 
earlier—that is, adding T = (Reverse(#S) o #T)—students can now make the necessary cognitive 
leap to realize the clause must be changed to read: Reverse (S) o T = Reverse (#S) o #T, resulting 
in a final, provable assertion that reads: D = |S| and Reverse (S) o T = Reverse (#S) o #T. 

4.2 Applying Iterative Invariant Development 

Following an introduction to the iterative development of loop invariants and discussion, students used 
the Web IDE to complete reasoning assignments. The assignments required students to write verified 
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code for pre-specified concepts and enhancement operations. The specification of one such operation to 
copy a generic Preemptable_Clueue is given below. 

Operation Copy_Queue 

(restores Q: P_Queue; replaces Q_Copy: P_Queue); 

ensures Q_Copy = Q; 

Table [T] is a summary of student performance for each of the invariant writing assignments. In ad¬ 
dition to copying a queue, students wrote code for outputting a queue, reversing a sequence, and an end 
user application assignment that involved use of custom-made mathematical definitions and operations 
involving non-trivial types. The definitions in the end user assignment were not complemented by nec¬ 
essary results and hence, the prover was not of use in establishing the invariants. The complexity of the 
assignment, the mathematics involved, and the absence of prover support are among possible reasons for 
the low success rate of students in developing appropriate invariants for those operations. 



Writing (Queue) 

Copying (Queue) 

Reversal (Sequence) 

Facility Operations 

Correct 

70% 

90% 

60% 

30% 

Insufficient Invariant 

20% 

10% 

30% 


Other 

10% 


10% 

70% 


Table 1: Evaluation of Invariant Assignments 

Fig. is an example of code developed by a student for the Copy_Queue assignment]^ Neither the 
code nor the invariant is necessarily optimal. Proofs of all 18 VCs generated for this copy operation are 
completed in an average time of 3 seconds (total) on the server that hosts the Web IDE. As noted earlier 
in the introduction, other provers, such as Z3, could be used to discharge the VCs. 


5 Summary of the Prover Underlying the Web IDE 

The verifying compiler that serves as the back end of the web interface contains a modular VC gen¬ 
eration subsystem ||8l |T5l which provides input to an automated prover. The automated prover relies 
on previously proven results in a library of mathematical theories that are reused in the specification of 
programming concepts lf34l . 

At the core of the CCVerify automated VC prover is a congruence closure algorithm that incorporates 
the Theory of Equality, similar in spirit to that described in Il28l . An outer layer that incorporates pattern 
matching techniques for expressions containing universally quantified variables is engaged, similar to the 
matcher described in IfTOll . In this way, a single component can handle problems from multiple domains. 
CCVerify, which contains fewer than 2000 lines of Java code, is designed to be fast, simple, and effective. 
As it is fully integrated into the compiler, there are no issues with portability, licensing, or translation of 
the assumptions to other formats as there might be if an external tool were used. 

There is an implied division of labor in the production of proofs. Specifications must be written 
so that the consequent of the VC eventually produced is a predicate with constants as arguments. It 

®In the figure, changing clause is optional and it lists variables potentially affected by the loop; variables not mentioned 
are assumed to be unchanging. In the absence of this clause, all variables are assumed to be affected. This clause is useful to 
simplify some routine invariants US). 
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2 Realization Iterative.Copying.Realiz 

3 C 

4 Operation Copy_EntryCrestores E: Entry; replaces R: Entry); 

5 ensures R = E; 

6 ) 

7 for Copying_Capability of PrGGinptablG_Queue_TGmplate; 

^ 8 Procedure Copy_QuGueC restores Q: P_QueuG; replaces Q_Copy: P_QueU' 

9 Var I, J: Integer; 

10 Var Q_Length: Integer; 

11 Var Tempi : Entry; 

12 Var Temp2: Entry; 

13 Var TempQ: P_Queue; 

14 ClearCQ-Copy); 

15 I := LengthCQ); 

16 While I > 0 

17 changing Tempi, TempZ, TempQ, I, Q, Q_Copy; 

18 maintaining #Q = Q_Copy o Q and I <= l#QI and IQI = I 

^19 and TempQ = Q_Copy; 

<©20 decreasing I; 

21 do 

<©22 DequeueCTempl, Q); 

23 Copy_Entry(Templ,Temp2); 

<©24 EnqueueCTempl, TempQ); 

<©25 EnqueueCTemp2, Q_Copy); 

26 I := LengthCQ): 

27 end; 

28 TempQ :=: Q; 

29 end Copy.Queue; 

30 end ItGrative_Copying_RGaliz;| 
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Figure 8: Student code for the Queue copy assignment. 


turns out that typically it is sufficient to use only instances of previously proven universally quantified 
sfafemenfs (fhese are members of a reusable fheorem library) fo consfrucf a proof, assuming fhaf fhe 
specifications used fo generafe fhe VC make such a proof relatively obvious. Sophisficafed fechniques 
used in automated fheorem provers may nof be required fo discharge fhe VCs. We are currenfly fesfing 
fhis hypofhesis using a limifed version of Z3 as well. 

Our malhemafical specificafion sysfem is fealure-rich. If allows for polymorphic fypes and firsf class 
funclions. These feafures make a direct franslafion of some of our malhemafical fheories fo fhe sfandard 
many-sorfed firsf-order logic language fj] used in SMT proving impossible, fhough if is possible fo sup- 
porl fhese feafures relatively simple (in a sound, buf nof complete way) wifhin fhe mafching component 
of the integrated proven 

6 Related Work 

A summary of related specification/verification languages may be found in ifT^ . and tools or IDEs to 
facilitate their usage are discussed in the first proceedings of this workshop ifT^ . We discuss only the 
most related work in this section. 

Like RESOLVE that underlies the Web IDE discussed in this paper, Dafny is a programming and 
specification language intended for verification of functional correctness l[24ll . The Eiffel integrated lan¬ 
guage effort though initially focused on runtime assertion checking, is now supported by Eve llT4ll . 
the Eiffel Verification Environment, which includes the AutoProof ll^ tool for static verification. Both 
Dafny and AutoProof translate code and specifications into Boogie [Tf, an intermediate verification Ian- 
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guage. The Boogie tool can create VCs suitable as input to an SMT solver. An important distinction is 
that the RESOLVE compiler handles VC generation internally, and displays them in a format that makes 
it easy for users to connect problematic VCs with the code and specifications that produced them. 

Java Modeling Language (JML) is a specification/verification language for Java programs, and tools 
for the language include the ability to do runtime assertion checking Il22ll . JML does not have an IDE, but 
there are efforts to integrate JML as plugin to Eclipse HHH. Tools are available for ProB, an animation 
and a model checker for the B-Method, which is a formal method based on abstract machine notation 
111 |371. The VeriLast effort is aimed at verifying single/multi-threaded C and Java programs ifTTl l33]l . 
VeriLast also includes a GUI that is packaged into their code distribution. 

We are not alone in employing a formal methods IDE in education. Whereas our educational focus 
is mostly on software engineering aspects (though we have used the Web IDE to a limited extent in a 
discrete mathematics course), teaching discrete mathematics and specifications using an IDE is the focus 
of EoCaLiZe—an IDE that takes source code, specification properties, and machine-checkable proofs to 
produce executable OCaml code and checkable Coq input values lITSl [30l . Though our Web IDE does 
not support inferring loop invariants, invariant inference is a useful feature; an Eclipse plugin with a goal 
to infer object and loop invariants for C programs is discussed in |6l. 

7 Conclusions 

This paper has detailed an iterative approach for creating, debugging, and developing components that 
are correct with respect to their specifications, using an IDE equipped with a verification system. Us¬ 
ing several illustrative examples drawn from lectures and student assigments, we have explained how 
students and software engineers, in general, can develop provably correct software iteratively based on 
the VCs and feedback received from the RESOLVE Web IDE. Extensive experience with the IDE in 
the classroom indicates that students are indeed capable of producing correct software using the the IDE 
as discussed in this paper. While the present paper has focused only on functional correctness of code, 
the IDE includes features to create and view mathematical units and data abstraction realizations with 
representation invariants and abstraction relations, as well as for generating executable Java code from 
RESOLVE code lIMl . 

A variety of improvements to the IDE are in progress, ranging from minor visual improvements, 
such as highlighting VC buttons that correspond to unprovable VCs, to more significant ones, such as 
the creation and development of performance specifications and related correctness checks. 
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Concept Preemptable_Queue_TemplateCtype Entry; evaluates Max_Length: Integer); 
uses String_Theory; 
requires Max_Length > 0; 

Type Family P_Queue is modeled by StrCEntry); 
exemplar Q; 

constraint IQI <= Max_Length; 
initialization ensures Q = Empty_String; 

end; 


Operation EnqueueCalters E: Entry; updates Q: P_Queue); 
requires IQI < Max_Length; 
ensures Q = #Q o <#E>; 


Updates 


H 


The value passed in will have a purposeful 
change at the end of the operation. 

TZ 


Operation InjectCalters E: Entry; updates rlyueuey, 
requires IQI < Max_Length; 
ensures Q = <#E> o #Q; 

Operation Dequeue(replaces R: Entry; updates Q: P_Queue); 
requires IQI /= 0; 
ensures #Q = <R> o Q; 


Figure 9: Partial Preeinptable_Queue specification. 


















